%!TEX root = tesis-header.tex
\section{Propuesta de Solución e Implementación}

En este capitulo se presentaran los desarrollos y resultados obtenidos en el intento de implementar el juego. En muchos casos se podrá apreciar la dedicación de los autores al trabajar estos resultados, no obstante, también se apreciara lo que aun falta por desarrollar en futuros alcances. A continuación se dará un resumen de los prototipos de algunas áreas mencionadas en el capitulo anterior.
\subsection{Escena}
Se hicieron cuatro escenas que ejemplifican los inicios del juego ``Lia fail''. Como son la presentación final del diseño artístico del juego, sirvieron para visualizar el desarrollo de sus elementos conformantes que se mencionaran posteriormente.

\subsubsection{Hibernia}
El primero de las escenas que se trabajo fue hecho pensando en una animación para la introducción del juego. Se puede apreciar en esta escena a varios elementos: el uso de shaders en el agua, el uso prominente del terreno, el uso de niebla y el uso de objetos móviles (el barco).

\begin{figure}[H]
\centering
\includegraphics[scale=0.4]{img/hibernia.png}
\caption{Vista del barco romano llegando a Hibernia}
\label{fig:hibernia}
\end{figure}

\subsubsection{Playa de Hibernia}
Aquí se puede apreciar una de las primeras escenas que se tenia en mente desde el principio del desarrollo del juego. Vemos a uno de los primeros personajes que se hicieron para el proyecto (el nativo anciano, o cubo). También se aprecia el uso de shaders en el agua y el uso de terreno. Faltaria en esta escena geometrías que representan arboles y montañas en el fondo (a falta de tiempo, ya no se integro este fondo a la escena).

\begin{figure}[H]
\centering
\includegraphics[scale=0.4]{img/playa-hibernia.png}
\caption{Playa de Hibernia con un personaje}
\label{fig:playahibernia}
\end{figure}

\subsubsection{Camino a Laigain}
Es la ultima escena en crearse. Se puede notar a un personaje enemigo. Aquí se tiene estipulado que se desarrollaría la primera batalla en el juego. De nuevo se nota la falta de un fondo con arboles. 

\begin{figure}[H]
\centering
\includegraphics[scale=0.4]{img/camino-laigain.png}
\caption{El Camino a Laigain con un enemigo}
\label{fig:caminolaigain}
\end{figure}

\subsubsection{Laigain}
El pueblo de Laigain, en donde se llevo la mayor cantidad de trabajo en modelar. Se aprecian nuevos elementos como chozas, Billboards y el ultimo de los personajes (Pip). También se le tenia destinado un fondo con montañas y arboles pero, al igual que las escenas anteriores, ya no se pudo incorporar por falta de tiempo. 

\begin{figure}[H]
\centering
\includegraphics[scale=0.4]{img/laigain.png}
\caption{El pueblo de Laigain}
\label{fig:laigain}
\end{figure}

\subsection{Personajes}
Fuera de los personajes que se tenían ya hechos en la preproducción, se agregaron algunos mas para representar a los malvados del juego y los soldados constituyentes de los equipos de batalla. En breve daremos una descripción de cada uno.

\subsubsection{Pip}
Pip, aparte de ser la personalidad principal del juego, también fue el modelo con el cual se hicieron la mayoría de las pruebas de modelaje en 3D Studio Max. A partir de el se dejo de usar el modelador 3dsmax y se modelaron los siguientes en Blender. El personaje también posee una animación para caminar.

\begin{figure}[H]
\centering
\includegraphics[scale=0.4]{img/pers-pip.png}
\caption{Pip}
\label{fig:perspip}
\end{figure}

\subsubsection{Soldados bueno (azules) malos (rojos) }
Básicamente parten de la misma maya en 3D Studio Max. Sus diseños se basaron en dibujos conceptuales alternativas de Pip.

\begin{figure}[H]
\centering
\includegraphics[scale=0.4]{img/red-blue.png}
\caption{Soldado bueno enfrentando a soldado malo}
\label{fig:persmalovsbueno}
\end{figure}

\subsubsection{Cubo/Anciano Nativo}
Primer personaje hecho en Blender. Demuestra una gran cantidad de animaciones y técnicas de texturización (a partir de wrapping UVW). Con este personaje se representa uno de los primeros personajes imaginados para la historia (aunque menos sarcásticamente). Se espera que, junto con Pip, sea uno de los personajes que se pueden controlar en modo estratégico en un futuro.

\begin{figure}[H]
\centering
\includegraphics[scale=0.4]{img/pers-hombrex.png}
\caption{Cubo/Anciano Nativo}
\label{fig:perscubo}
\end{figure}

\subsubsection{Pepito/Enemigo}
En realidad este personaje es la mascota oficial de uno de los proyectos del Dep. de Realidad Virtual en DGSCA (Ve3D), pero su personalidad bélica lo hizo víctima de una aparición cameo en el juego, para finalmente asentarse como uno de los personajes malévolos. También se modelo en Blender y no presenta animaciones por falta de tiempo.

\begin{figure}[H]
\centering
\includegraphics[scale=0.4]{img/pers-pepito.png}
\caption{Pepito/Enemigo}
\label{fig:perspepito}
\end{figure}

\subsubsection{Barco Romano}
Propiamente no es un personaje pero posee un rasgo singular en todo el juego, ya que no es un inmueble que forma parte del escenario ni tampoco es un personaje con los mismos atributos de formar un elemento estratégico. Es el único móvil que se contempla en todo el juego por el cual es un elemento interactivo. Se modelo a partir del esquema de un barco romano mediterráneo. Presenta rasgos parecidos a un barco explorador vikingo, por lo que solo se puede imaginar si de veras lo hubieran usado los romanas (de los primeros años del imperio) para alcanzar Hibernia.

\begin{figure}[H]
\centering
\includegraphics[scale=0.4]{img/pers-barco.png}
\caption{Barco Romano}
\label{fig:persbarco}
\end{figure}

\subsection{Terrenos}

Se hace hincapié en que el diseño de estos terrenos no fue un asunto trivial. A pesar de que OGRE sí dispone de todas las ventajas que ofrece OpenGL 2.0 (para ser preciso, OpenGL 1.5 + extensiones), se remite a usar los pixel-shaders lo menos posible (a menos que a alguien se le ocurre programar el uso de shaders en el modulo de terrenos). Siendo así entonces, ya los terrenos generados no se ven afectados por las luces ni por ciertas características del ambiente. Esto da, como consecuencia, la falta de sombras en los terrenos, lo que implica el uso de un viejo truco visual, que antes se usaba en los juegos, llamado Texture Baking (literalmente dorar una textura). En seguida se explica este proceso.

\newpage

\subsubsection{Texture Baking}

En un modelador se usa otro tipo de pipeline de rendering para llegar a obtener resultados convincentemente reales o fotorealisticos (los cuales ya no sirven para dibujarse en tiempo real). Estos pipelines prestan sus cálculos intensivos y tardados para hacer una `pos-producción' a las texturas que se van a usar en la escena generado en tiempo real.
Los pipelines de rendering fotorealistico derivan de un algoritmo (en su mayoría) que fue usado por primera vez en LucasFilm, en Point Reyes California. El pipeline Reyes (desarrollado por la misma división LucasFilm que mas tarde se llamaria Pixar) simula casi todos los efectos reales y estocásticos de la luz natural, por medio de Ray-tracing. El Raytracing tiene sus orígenes en un programa que originalmente calculaba las trayectorias (y energías) de partículas radioactivas en un reactor nuclear. Debido a la naturaleza tan cercana que tienen estas partículas a los fotones, se integro al rendering fotorealistico. A consecuencia se tienen reflejos, refracciones, filtros y sombras muy parecidos a la vida real.

Se puede apreciar en la figura~\ref{fig:txba} como se ve el terreno de una playa en OGRE al corregirle gradualmente la textura y otro efecto visual que se llama bump-mapping (otra vez relieve). El programa que se uso para el texture baking de los terrenos fue 3D Studio Max.

\begin{figure}[htp]
    \centering
    \subfigure[Imagen sin texture baking]{
        \label{fig:txb1}
        \includegraphics[scale=0.6]{img/beach.jpg}}
    \vspace{.1in}
    \subfigure[Con texture Baking]{
        \label{fig:txb2}
        \includegraphics[scale=0.6]{img/beach2.jpg}}
	\caption{Desarrollo de un terreno con Texture Baking} 
	\label{fig:txba}
\end{figure}
\vspace{.1in}
\begin{figure}[htp]
	\centering
    \subfigure[Hasta aquí se ve fantástico la playa, pero ahora se va a experimentar con el bump-map de OGRE para observar cuanto mejora]{ 
        \label{fig:txb3}
        \includegraphics[scale=0.6]{img/beach3.jpg}}
    \vspace{.1in}
    \subfigure[Después de hacer mas brillante al bump map (150 veces mas)]{
        \label{fig:txb4}
        \includegraphics[scale=0.6]{img/beach4.jpg}}
    \caption{Desarrollo de un terreno con Texture Baking 2} 
    \label{fig:txbb}
\end{figure}

\subsection{Billboards}

En los escenarios de Lia Fail se contemplaba usar Billboards para arboles y plantas principalmente. Su diseño involucraba mucha mas habilidad con cámaras y editores de bitmaps que con el propio código de OGRE o el cargador de XML.

Tomando como ejemplo a uno de los Billboards, el primero que se diseño, una planta que se encontró a lado de la rampa bicipuma (entre el anexo de ingeniería y la facultad de contaduría, en Ciudad Universitaria). Es un ejemplo de Billboard de los mas ideales debido a varios factores que mencionaremos a continuación. Siendo que estaba totalmente aislado de las otras plantas se elimino la necesidad de filtrar que partes eran de la misma planta y cuales eran de alguna otra planta.

Otro factor igual de importante fue que la planta no presentaba detalles muy finos. A un profesional que se dedica a trabajar texturas no le convendría tener que invertir mucho tiempo limpiando los bordes de una planta cuyas partes resultan ser de tres a un pixel de grosor. Se sugiere encontrar un objeto con detalles de gran grosor, a menos que sea totalmente necesario para el escenario.

El siguiente factor importante fue que el fondo estuviera monocromático, esto es, que el fondo solo tuvo un color o tono lo cual también facilita enormemente la separación de la planta del fondo. Si se pregunta uno, en las películas donde no tuvieron una pantalla azul (o verde) de fondo y nada mas tienen la película original (con una variedad de fondos), ¿Porqué sale el proceso de cambiar el fondo o transportar al actor, tan caro y minuciosa? Es por lo mismo pero multiplicado por la cantidad de cuadros involucrados en esa escena. El fondo de la foto fue concreto blanco, lo que deja que nada mas se limpiara partes con distintos tonos de luz o que se veían sucios.

Un ultimo factor para escoger un Billboard ideal es el efecto de la luz sobre el objeto. Esto se nota en la figura~\ref{fig:mario} (pag.~\pageref{fig:mario}), donde el Rey Bob-Omb se ve en 3D debido a un reflejo del sol que nunca se mueve pero engaña lo suficientemente bien al usuario para hacerlo pensar que es una esfera en 3D. En la planta se observa un efecto parecido lo cual lo hace muy ideal para que se situé en medio de un campo abierto o al borde de un bosque, pero no dentro de uno. En dado caso que se quisiera situar la planta dentro de un bosque se auxilia de unas paraguas, antes de tomar la foto, para que no le pegue el sol.

Viene en seguida el pos-procesamiento de la imagen digital, donde se limpia la imagen de todo lo innecesario usando canales alfa. Dentro de las definiciones de materiales para OpenGL (y de manera derivada, en OGRE) se usan Mapas de bits de 3 o 4 bytes y de dimensiones que siempre se rigen en potencias de 2 para la fácil manipulación de la textura (normalmente sufre mutaciones al encimarse a la geometría). En este caso no se desea que el material sufra distorsiones al trasladarse al plano del Billboard. Para lo anterior la imagen se manipulo de tal forma que se viera bien siendo cuadrado y con el canal alfa se eliminaron todos los detalles y elementos demás que lo hiciera parecer como un mapa de bits cuadrada. Al final se guarda la imagen en un formato que soporta 32 bits (es decir, que soporta canales alfa) que pueden ser formato TARGA, PNG o TIFF. GIF es un formato opcional por si no se requiere de una gran gama de colores (En su caso se usa uno de sus colores indexados para efectos de transparencia).

Se puede apreciar los Billboards en la escena de Laigain en las figuras~\ref{fig:billboard} y \ref{fig:billboard2}.

\begin{figure}[htp]
\centering
	\subfigure{
		\label{fig:billboard1a}
		\includegraphics[scale=0.4]{img/screenshot_1.png}}
	\hspace{.1in}
	\subfigure{
		\label{fig:billboard1b}
		\includegraphics[scale=0.4]{img/screenshot_2.png}}
\caption{Billboards 1}
\label{fig:billboard}
\end{figure}

\begin{figure}
	\subfigure{
		\label{fig:billboard2a}
		\includegraphics[scale=0.4]{img/screenshot_3.png}}
	\hspace{.1in}	
	\subfigure{
		\label{fig:billboard2b}
		\includegraphics[scale=0.4]{img/screenshot_4.png}}
\caption{Billboards 2}
\label{fig:billboard2}
\end{figure}

Una de las cosas mas importantes al usar Billboards es su ubicación y la cantidad de veces que se usan. Como se había mencionado antes se usan con menos frecuencia en los nuevos videojuegos debido a que se tiende a explotar mas la capacidad de las nuevas tarjetas gráficas para hacer escenas mas realistas y convincentes, disminuyendo su utilidad. OGRE tiene un sistema de Billboards pero por lo mismo anterior, ha tenido poca popularidad y por lo tanto no se implemento en el cargador XML original. Gran parte del tiempo invertido en el desarrollo del cargador de escenas es debido a la programación de Billboards (al igual que los shaders).

Los Billboards en OGRE llevan una gran cantidad de opciones debido, mas que nada, al uso de arreglos. Los Billboards no se pueden definir individualmente en OGRE pero si se pueden crear arreglos con un solo Billboard, lo que complica su definición en XML. Gran parte de su declaración en XML ya estaba hecho y nada mas faltaba programar la correspondencia entre la etiqueta en XML y la clase Billboard. Visto desde un punto de vista, los Billboards eran arboles dentro del árbol de nodos en el grafo de escena, entonces la programación fue pensado en términos de como redefinir una etiqueta que actúe como si fuera una etiqueta <node>.

\subsection{Shaders}

OGRE tiene soporte para tres variantes de Shaders: HLSL, GLSL y Cg. Para la necesidad particular del juego, en donde el único caso en donde se contemplaba el uso de shaders era la generación de agua, se decidió usar el lenguaje mas portátil de entre los tres - Cg. Todos los lenguajes de shaders tienen al menos 2 áreas donde se aplica la programación de shaders, estos son vértices y fragmentos (o pixeles en HLSL). En OGRE se llega a distinguir entre estas dos áreas pero se manejan como materiales.
Como se menciono anteriormente el único shader que se llego a implementar en el juego, fue el shader del agua. Este shader tiene su propia etiqueta XML para incluirlo en casi  cualquier escena. No se puede apreciar muy bien en las figuras~\ref{fig:hibernia} y \ref{fig:playahibernia}, pero en esas escenas se llegan a usar. El shader de este elemento calcula en tiempo real una serie de ondulaciones en el agua que afecta tanto a su geometría como a su textura.

\subsection{Manejo de escenas por XML}

En un principio se tenia la idea de programar toda la carga de escenas por medio del engine. Se llego a la anterior conclusión por la forma en como estaba codificado la mayoría de los juegos (o se pensó). En realidad es muy distinto tener un metalenguaje, como UnrealScript, a tener una librería que se encarga de cargar todo a memoria, aunque se puede ver a uno como el inicio del otro (a pesar de que el XML no es un lenguaje Turing completo). Se puede decir que el cargador de XML es un intento de scripting provisional.

La librería de cargas de escena del juego principalmente es un derivado de otra librería que no tuvo licencia pero sí una serie de autores quienes dejaron su documentación en las siguientes paginas:

\url{http://www.ogre3d.org/wiki/index.php/DotScene_Loader_with_User_Data}
\url{http://www.ogre3d.org/wiki/index.php/DotScene_Loader_with_User_Data_Class}
\url{http://www.ogre3d.org/wiki/index.php/New_DotScene_Loader}

A la hora de escribir, esta librería ya presenta ciertas adiciones, necesarios para el juego de Lia Fail, que ya se han mencionado: El manejo de Billboards en escenas y el manejo de un plano con efectos de agua (por medio de shaders).

En un desarrollo posterior se tiene contemplado incluir los siguientes elementos:
\begin{quote}
\begin{itemize}
\item Manejo de música de fondo y atributos de control sonido para los nodos (esto para tener un efecto de sonido al realizarse una acción en un objeto).
\item Manejado de Escenas pre-animadas (películas).
\item Manejo de Física y colisiones en la escena.
\item Manejo de Atributos de los personajes.
\end{itemize}
\end{quote}

\section{Integración}
La integración de algunos de los elementos anteriormente mencionados, específicamente los que conforman a la escena de Laigain, con el motor del juego desarrollado sera el objetivo final de la aplicación de demostración. Se espera que con la aplicación de demostración para plataforma Macintosh se logre representar la visión original del videojuego de Lia Fail.

El prototipo del juego se logró integrando el uso de recursos como colisiones, gravedad, interacción con el teclado, seguimiento de cámaras en la escena junto con el cargador de escenas directamente en el código fuente del programa demo. Finalmente se tuvo un motor que siguiera los lineamientos del motor del juego Quake, y no así la idea del motor del juego Unreal. Aun así, el resultado final es la creación de un motor versátil al que posteriormente será posible agregar características adicionales en el futuro.

Fue necesario, en la programación, relacionar los elementos de la escena con un correspondiente objeto de colisión conocido como ``World'', un objeto de la librería OgreOde. Por el cual se hizo un relación de cual de los elementos de la escena se le asignaría el papel de personaje principal para hacer posible un punto de vista en tercera persona, esto es, el seguimiento de cámara. Lo que siguió fue la programación de los interfaces con el personaje principal e afirmar que todo los objetos de la escena cumplían con efectos de física y colisión.

Lo que se tiene al final es una aplicación, para ejecutarse en el sistema operativo Mac OS X (preferiblemente 10.5), que ejemplifica, de manera rudimentaria, la implementación parcial de un videojuego según los rubros estipulados al principio de la tesis.